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Abstract 


Hardware  description  languages  (HDLs)  are  used  today  to  describe  circuits  at  all  levels.  In 
large  HDL  programs,  there  is  a  need  for  source  code  reduction  techniques  to  address  a  myriad 
of  problems  in  design,  simulation,  testing,  and  formal  verification.  Program  slicing  is  a  static 
program  analysis  technique  that  allows  an  analyst  to  automatically  extract  portions  of  programs 
relevant  to  the  aspects  being  analyzed.  We  extend  program  slicing  to  HDLs,  thus  allowing 
for  automatic  program  reduction  to  let  the  user  focus  on  relevant  code  portions.  We  have 
implemented  a  VHDL  slicing  tool  composed  of  a  general  inter-procedural  sheer  and  a  front-end 
that  captures  VHDL  execution  semantics.  This  report  provides  an  introduction  to  the  theory 
of  inter-procedural  program  slicing,  a  discussion  of  how  to  slice  VHDL  programs,  a  description 
of  the  resulting  tool,  and  a  discussion  of  some  applications  and  experimental  results. 


1  Introduction 


Hardware  description  languages  (HDLs)  are  used  today  to  describe  circuits  at  all  levels  from 
conceptual  system  architecture  to  low-level  circuit  implementations  suitable  for  synthesis.  HDL 
source-code  simulation  is  a  common  technique  for  analyzing  the  resulting  descriptions  and 
debugging  the  design  before  implementation.  However,  a  major  lack  in  current  source-code¬ 
simulation  methodologies  is  the  need  for  structured  design  and  analysis  techniques  that  can 
be  applied  to  the  simulation  process.  The  need  for  structured  development  methodologies  is 
becoming  even  more  important  with  the  increased  use  of  reusable  libraries  of  existing  code, 
since  it  is  difficult  to  use,  modify,  and/or  maintain  unstructured  libraries.  Thus,  major  needs 
for  source  code  simulation  include  support  for  testing,  debugging,  and  maintenance  of  the 
simulations.  There  are  also  several  tools  that  apply  model  checking  ([!])  to  formally  verify 
correctness  of  HDL  designs  (one  such  system  for  VHDL  is  described  in  [2]).  It  is  well  recognized 
that  the  fundamental  problem  in  model  checking  is  state  explosion,  and  there  is  consequently 
a  need  to  reduce  the  size  of  HDL  descriptions  so  that  their  corresponding  models  have  fewer 
states.  For  many  designs,  it  is  not  even  possible  to  build  the  state  transition  relation,  and  the 
need  for  HDL  program  reduction  techniques  is  even  more  critical  in  these  cases. 

Several  of  these  desiderata  have  close  parallels  in  the  software-engineering  domain,  where 
it  is  desirable  to  understand  and  manipulate  large  programs.  This  is  difficult  to  do,  partly 
because  of  the  presence  of  large  quantities  of  irrelevant  code.  Program  slicing  was  defined  by 
Weiser  [3]  to  cope  with  these  problems  by  performing  automatic  decomposition  of  programs 
based  on  data-  and  control-flow  analysis.  A  program  slice  consists  of  those  parts  of  a  program 
that  can  potentially  affect  (or  be  affected  by)  a  slicing  criterion  (i.e.,  a  set  of  program  points 
of  interest  to  the  user).  The  identification  of  program  slices  with  respect  to  a  slicing  criterion 
allows  the  user  to  reduce  the  original  program  to  one  that  is  simpler  but  functionally  equivalent 
with  respect  to  the  slicing  criterion. 

Results  of  program  slicing  in  the  software  engineering  world  suggest  that  the  techniques 
can  also  be  applied  to  HDLs  to  solve  many  of  the  problems  mentioned  above.  However,  most 
traditional  program  slicing  techniques  are  designed  for  sequential  procedural  programming  lan¬ 
guages,  and  the  techniques  are  not  directly  applicable  to  HDLs,  which  have  a  fundamentally 
different  computation  paradigm.  An  HDL  program  is  a  non-halting  reactive  system  composed 
of  a  set  of  concurrent  processes,  and  many  HDL  constructs  have  no  direct  analogue  in  more  tra¬ 
ditional  programming  languages.  In  this  report  we  present  an  approach  for  slicing  VHDL  based 
on  its  execution  semantics.  Our  approach  is  based  on  a  mapping  of  VHDL  constructs  onto  tra¬ 
ditional  programming  language  constructs,  in  a  way  that  ensures  that  all  traces  of  the  VHDL 
program  will  also  be  valid  traces  in  the  corresponding  sequential  program.  Corresponding  to 
this  approach,  we  have  also  implemented  a  VHDL  slicing  tool  consisting  of  a  VHDL  front-end 
coupled  with  a  language-independent  toolset  intended  for  inter-procedural  slicing  of  sequential 
languages  such  as  C.  We  have  also  applied  the  tool  to  some  formal  verification  problems,  and 
have  achieved  substantial  state  space  reductions. 

The  remainder  of  the  report  is  organized  as  follows:  Section  2  presents  requisite  background 
material  while  Section  3  presents  our  techniques  for  performing  language-independent  interpro¬ 
cedural  slicing.  Section  4  shows  how  we  capture  VHDL  semantics  for  slicing.  Section  5  describes 
the  architecture  and  implementation  of  the  VHDL  slicing  tool,  and  provides  a  walkthrough  of  a 
simple  VHDL  example.  Section  6  lists  many  applications  of  slicing,  and  provides  experimental 
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results  that  concretely  illustrate  the  benefits  of  slicing  in  reducing  state  space  size  for  model 
checking.  We  compare  and  contrast  our  work  with  other  approaches  in  Section  7.  Finally, 
Section  8  summarizes  our  conclusions  and  briefiy  discusses  our  future  plans  in  this  area. 


2  Background 

Slicing  is  an  operation  that  identifies  semantically  meaningful  decompositions  of  programs, 
where  the  decompositions  consist  of  elements  that  are  not  necessarily  textually  contiguous 
[4,  3,  5,  6,  7,  8].  (See  [9,  10]  for  surveys  on  slicing.)  Slicing,  and  subsequent  manipulation 
of  slices,  has  applications  in  many  software-engineering  tools,  including  tools  for  program  un¬ 
derstanding,  maintenance  [11],  debugging  [12],  testing  [13,  14],  differencing  [15,  16],  specializa¬ 
tion  [17],  reuse  [18],  and  merging  [15]. 

There  are  two  kinds  of  slices:  a  backward  slice  of  a  program  with  respect  to  a  slicing  criterion 
C  is  the  set  of  all  program  elements  that  might  affect  (either  directly  or  transitively)  the  values 
of  the  variables  used  at  members  of  (7;  a  forward  slice  with  respect  to  C  is  the  set  of  all  program 
elements  that  might  be  affected  by  the  computations  performed  at  members  of  C . 

A  related  operation  is  program  chopping  [19,  20].  A  chop  answers  questions  of  the  form 
“Which  program  elements  serve  to  transmit  effects  from  a  given  source  element  s  to  a  given 
target  element  t?  .  Given  a  set  of  source  program  points  S  and  a  set  of  target  program  points 
T,  the  chop  consists  of  all  program  points  that  might  be  affected  by  assignments  performed  at 
S  that  can  affect  the  values  of  variables  used  at  T. 

It  is  important  to  understand  the  distinction  between  two  different  but  related  “slicing 
problems” : 

Version  (1)  (Closure  Slice)  The  slice  of  a  program  with  respect  to  program  point  p  and 
variable  x  identifies  all  statements  and  predicates  of  the  program  that  might  affect  the 
value  of  X  at  point  p. 

Version  (2)  (Executable  Slice)  The  slice  of  a  program  with  respect  to  program  point  p 
and  variable  x  produces  a  reduced  program  that  computes  the  same  sequence  of  values 
for  X  at  p.  That  is,  at  point  p  the  behavior  of  the  reduced  program  with  respect  to  variable 
X  is  indistinguishable  from  that  of  the  original  program. 

In  mtraprocedural  slicing,  a  solution  to  Version  (1)  provides  a  solution  to  Version  (2),  since  the 
reduced  program  required  in  Version  (2)  can  be  obtained  by  restricting  the  original  program 
to  just  the  statements  and  predicates  found  in  the  solution  for  Version  (1);  in  wferprocedural 
slicing,  where  a  slice  can  cross  the  boundaries  of  procedure  calls,  it  turns  out  that  a  solution  to 
Version  (1)  does  not  necessarily  provide  a  solution  to  Version  (2)  since  a  slice  may  contain  dif¬ 
ferent  subsets  of  a  procedure’s  parameters  for  different  call  instances  of  the  same  procedure  [7]. 
However,  a  solution  to  Version  (1)  can  always  be  extended  to  provide  a  solution  to  Version  (2) 
[21].  Our  system  does  closure  slicing,  with  partial  support  for  executable  slicing. 

A  second  major  design  issue  is  the  type  of  interprocedural  slicing.  Some  slicing  and  chop¬ 
ping  algorithms  are  precise  in  the  sense  that  they  track  dependences  transmitted  through  the 
program  only  along  paths  that  reflect  the  fact  that  when  a  procedure  call  finishes,  control  re¬ 
turns  to  the  site  of  the  corresponding  call  [7,  8,  20].  In  contrast,  other  algorithms  are  imprecise 
in  that  they  safely,  but  pessimistically,  track  dependences  along  paths  that  enter  a  procedure 
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at  one  call  site,  but  return  to  a  different  call  site  [22,  19].  Precise  algorithms  are  preferable 
because  they  return  smaller  slices.  Precise  slicing  and  chopping  can  be  performed  in  polynomial 
time  [7,  8,  20].  Our  VHDL  slicing  tool  supports  precise  interprocedural  slicing  and  chopping. 


3  Inter-Procedural  Slicing 

The  value  of  a  variable  y  used  at  p  is  directly  affected  by  assignments  to  y  that  reach  p  and  by 
the  predicates  that  control  how  many  times  p  is  executed.  Similarly,  the  value  of  a  variable  x 
defined  at  p  is  directly  affected  by  the  values  of  the  variables  used  at  p  and  by  the  predicates 
that  control  how  many  times  p  is  executed.  Consequently,  a  slice  can  be  obtained  by  following 
chains  of  dependences  in  the  directly-affects  relation.  This  observation  is  due  to  Ottenstein 
and  Ottenstein  [5],  who  noted  that  procedure  dependence  graphs  (PDGs),  which  were  originally 
devised  for  use  in  parallelizing  and  vectorizing  compilers,  are  a  convenient  data  structure  for 
slicing.  PDGs  for  the  procedures  in  a  program  can  be  combined  to  form  a  system  dependence 
graph  (SDG),  upon  which  our  inter-procedural  slicing  algorithms  are  based. 

The  PDG  for  a  procedure  is  a  directed  graph  whose  vertices  represent  the  individual  state¬ 
ments  and  predicates  of  the  procedure.  Vertices  are  included  for  each  of  the  following  constructs: 

•  Each  procedure  has  an  entry  vertex. 

•  Each  formal  parameter  has  a  vertex  representing  its  initialization  from  the  corresponding 
actual  parameter. 

•  Each  assignment  statement  has  a  vertex. 

•  Each  control-structure  condition  (e.g.  if)  has  a  vertex. 

•  Each  procedure  call  has  a  vertex. 

•  Each  actual  parameter  to  a  procedure  has  a  vertex  representing  the  assignment  of  the 
argument  expression  to  some  implicit  (generated)  variable. 

•  Each  procedure  with  a  return  value  has  a  vertex  representing  the  assignment  of  the  return 
value  to  some  generated  name. 

•  Each  formal  parameter  and  local  variable  has  a  vertex  representing  its  declaration. 

A  procedure’s  parameters  may  sometimes  be  implicit.  If  a  procedure  assigns  to  or  uses  a  global 
variable  x  (either  directly  or  transitively  via  a  procedure  call),  x  is  treated  as  an  “hidden” 
input  parameter,  thus  giving  rise  to  additional  actual-in  and  formal-in  vertices.  Similarly,  if 
a  procedure  assigns  to  a  global  variable  x  (either  directly  or  transitively),  x  is  treated  as  a 
“hidden”  output  parameter,  thus  giving  rise  to  additional  actual-out  and  formal-out  vertices. 

Denote  the  program  code  corresponding  to  a  vertex  V  as  ^V.  PDG  vertices  are  connected 
through  the  following  types  of  edges: 

•  There  is  a  flow  dependence  edge  between  two  vertices  Vi  and  V2  if  there  exists  a  program 
variable  x  such  that  vi  can  assign  a  value  to  a;,  U2  can  use  the  value  in  x,  and  there  is  an 
execution  path  in  the  program  from  ^Vi  to  jj^V2  along  which  there  is  no  assignment  to  x. 
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FUNCTION  add(a,b) 
retum(a+b); 
FUNCTION  mainO 
sum  <=  0; 
i<=  1; 

while  (i  <  11) 

sum  <=  add(sum,i); 
i<=add(i,l); 
print(sum); 
print(i); 


Figure  1:  Sample  SDG 

•  There  is  a  control  dependence  edge  between  a  condition  vertex  and  a  second  vertex  v 
if  the  truth  of  the  condition  of  ^Vc  controls  whether  or  not  is  executed. 

•  There  is  a  declaration  edge  from  the  declaration  vertex  for  a  program  variable,  x,  to  each 
vertex  that  can  reference  x. 

•  There  is  a  summary  edge  corresponding  to  each  indirect  dependence  from  a  procedure 
call  s  actual  parameters  and  its  output(s).  These  edges  are  used  to  avoid  recomputing 
these  summary  relationships,  thus  making  inter-procedural  slicing  more  efficient.  They 
are  actually  computed  after  PDG  construction. 

Given  PDGs  for  each  procedure,  a  system  dependence  graph  (SDG)  is  then  constructed  by 
connecting  the  PDGs  appropriately  using  the  following  additional  types  of  edges: 

•  There  is  a  call  edge  from  a  procedure  call  vertex  to  the  corresponding  procedure  entry 
vertex. 

•  There  is  a  parameter-in  edge  between  each  actual  parameter  and  the  corresponding  formal 
parameter. 

•  There  is  a  parameter-out  edge  between  each  procedure  output  value  vertex  and  the  vertex 
for  an  implicit  (generated)  variable  on  the  caller  side  designated  to  receive  it. 

Figure  1  illustrates  a  SDG  for  a  small  pseudocode  program. 

The  complete  algorithm  for  building  a  SDG  from  a  program  involves  the  following  steps: 

1.  Build  a  Control  Flow  Graph  (CFG)  for  each  procedure  in  the  program. 

2.  Build  the  call  graph  for  the  program. 

3.  Perform  global  variable  analysis,  turning  global  variables  into  hidden  parameters  of  the 
procedures  that  reference  or  modify  them. 

4.  Construct  the  PDGs  by  doing  control-dependence  and  flow-dependence  analysis. 
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VHDL  Construct 

Traditional  Construct 

Procedure 

Function 

Process 

Concurrent  Assignment 

Procedure 

Architecture  variable 

Local  variable 

Signal,  Port 

Global  variable 

Sequential  Statement 

Statement 

Figure  2:  Mapping  of  VHDL  Constructs 


5.  Optionally  compress  the  PDG  so  that  each  strongly  connected  region  is  represented  by 
one  node. 

6.  Bring  together  the  PDGs  and  the  call  graph  to  form  the  SDG. 

7.  Compute  summary  edges  for  procedures  that  describe  dependences  between  the  inputs 
and  the  outputs  of  each  procedure. 

Then,  slices  and  chops  are  computed  by  following  the  chains  of  dependences  represented  in 
the  edges  of  the  SDG. 


4  VHDL  Slicing 

Rather  than  creating  an  independent  sheer  built  specifically  for  VHDL,  our  approach  is  to  map 
VHDL  constructs  onto  constructs  for  more  traditional  procedural  languages  (e.g.  C,  Ada), 
utilizing  the  semantics  provided  by  the  VHDL  LRM  [23].  Figure  2  lists  the  mapping  between 
VHDL  and  traditional  constructs  that  we  use. 

While  many  of  these  mappings  may  seem  obvious,  there  are  several  major  differences  be¬ 
tween  VHDL  and  traditional  programming  languages  which  complicate  the  generation  of  the 
SDG.  A  VHDL  program  executes  as  a  series  of  simulation  cycles,  as  illustrated  in  Figure  3. 


Figure  3:  Simplified  VHDL  simulation  cycle 
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The  VHDL  computational  paradigm  differs  fundamentally  from  traditional  languages  in 
three  ways: 

1.  A  VHDL  program  is  a  non-halting  reactive  system,  rather  than  a  collection  of  halting 
procedures. 

2.  A  VHDL  program  is  a  concurrent  composition  of  processes,  where  there  is  no  explicit 
means  for  these  processes  to  be  called  (in  the  manner  of  traditional  procedures). 

3.  VHDL  processes  communicate  through  multiple-reader  signals  to  which  they  are  sensitive, 
instead  of  through  parameters  defined  at  a  single  procedure  entry  point. 

VHDL  procedures  and  functions  are  modeled  in  the  traditional  way.  However,  VHDL 
process  models  must  capture  the  above  differences,  and  we  do  this  through  three  types  of 
modifications: 

•  The  constructed  CFGs  model  the  non-halting  reactive  nature  of  VHDL  processes. 

•  The  constructed  PDGs  capture  an  additional  dependence  corresponding  to  VHDL  signal 
communication. 

•  An  implicitly  generated  master  “main”  procedure  controls  process  invocation,  analogous 
to  the  event  queue  which  controls  VHDL  simulator  execution. 

These  mechanisms  are  described  below.  In  all  cases,  the  discussion  only  mentions  processes, 
though  it  is  to  be  understood  that  concurrent  statements  are  treated  analogously. 


4.1  Constructing  the  CFG 

GFG  construction  for  traditional  languages  is  well  understood,  and  the  identical  technique  is 
used  for  VHDL  procedures  and  functions.  VHDL  processes  require  some  CFG  modifications. 
We  first  consider  processes  with  an  explicit  sensitivity  list  or  a  single  wait  statement.  The  non¬ 
halting  nature  of  processes  is  modeled  simply  by  passing  control  from  the  end  of  the  process 
back  to  its  beginning.  The  wait  statement  provides  the  only  complication.  As  suggested  by 
Figure  3,  from  a  wait  statement,  either  control  passes  to  the  next  statement  or  the  simulation 
exits  (in  case  the  wait  condition  is  never  satisfied).  This  is  simple  to  capture  in  the  CFG  by 
creating  two  corresponding  child  control-flow  arcs  from  the  wait  statement.  Figure  4  illustrates 
a  CFG  for  a  simple  process. 

The  situation  is  substantially  more  complicated  when  there  are  multiple  wait  statements 
in  the  process.  Although  the  above  procedure  still  works  in  this  case,  the  resulting  slice  may 
be  substantially  larger  than  needed.  Since  each  wait  statement  corresponds  to  a  point  where 
a  region  of  the  process  may  be  invoked,  a  forward  slice  that  affects  a  wait  statement  needs  to 
include  only  the  portion  of  the  process  between  the  wait  statement  and  the  next  wait  statement 
(and  similarly  for  backward  slices).  To  model  this,  we  partition  each  process  into  regions 
corresponding  to  the  portion  of  the  process  between  successive  wait  statements  (see  Figure  5 
for  an  example). 

Note  that  we  only  require  that  each  end  node  of  a  region  precedes  a  wait  statement;  there 
may  be  multiple  end  nodes,  and  regions  may  overlap  in  the  presence  of  wait  statements  within 
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2  Usex 


Exit 


1  PROCESS  BEGIN 

2  WATTONx; 

3  IF(y=:’r) 

4  THEN  z  <=  x; 

5  END  IF; 

6  END  PROCESS; 


Figure  4:  Sample  CFG  (line  numbers  added  for  clarity) 


WATTONx 

y  <=’!’; 

z  <=x; 


region  1 

V 


WATT  ON  x2; 

IF(x2=’l’) 

THEN  WAIT  ON  x3;  A 
END  IF;  region  2 


region  3 


z  <=  x2; 


Figure  5:  Process  regions  in  the  presence  of  multiple  wait  statements 


branching  control  structures  (though  very  few  VHDL  programs  have  such  control  structures 
in  practice).  Then,  a  procedure  for  each  process  region  is  created,  and  a  CFG  for  each  of 
the  resulting  procedures  is  created  as  usual.  To  capture  context  information  between  process 
regions  within  the  same  process,  all  objects  local  to  the  process  (e.g.,  variables)  are  treated 
as  global  variables  after  renaming  to  avoid  conflicts  with  other  processes  (recall  that  the  SDG 
build  algorithms  treat  global  variables  as  hidden  parameters).  Thus,  for  a  process  with  W  wait 
statements,  W+1  procedures  are  created,  one  starting  at  each  of  the  wait  statements  and  one 
starting  at  the  beginning  of  the  process. 


4.2  PDG  Modifications 

In  traditional  languages,  inter-procedure  communication  occurs  through  global  variables  and 
parameters  explicitly  passed  from  the  calling  procedure  to  a  called  procedure.  In  contrast, 
VHDL  process  communication  occurs  through  signals,  and  a  process  (or  process  region)  is 
invoked  when  it  is  at  a  wait  statement  w,  and  there  is  an  event  for  a  signal  that  w  is  sensitive 
to.  This  communication  is  captured  through  the  notion  of  signal  dependence  (in  addition  to 
the  dependence  types  listed  in  Section  3):  A  process  region  p  is  said  to  be  signal  dependent 
on  statement  s  if  s  potentially  assigns  a  value  to  a  signal  that  p  is  sensitive  to.  Rather  than 
modeling  this  signal  dependence  explicitly  in  the  PDG,  we  generate  implicit  procedure  calls 
in  the  CFG  every  time  a  signal  is  potentially  assigned.  For  example,  every  assignment  to 
signal  s  is  followed  by  implicit  calls  to  every  procedure  (e.g.  VHDL  process  region,  concurrent 
assignment)  that  is  sensitive  to  s. 


4.3  The  Master  Process 


The  above  changes  do  not  handle  the  reactive  nature  of  VHDL,  since  processes  may  also  be 
invoked  by  events  on  input  ports.  For  simplicity,  the  following  discussion  deals  with  processes, 
though  the  same  arguments  are  also  applicable  to  process  regions.  Consider  a  VHDL  program 
n  =||"=i  P,-  wliere  the  Pi's  are  the  processes  comprising  the  program  (as  before,  other  concurrent 
statements  are  treated  as  one-line  processes  for  the  purposes  of  this  discussion).  Partition  H 
into  two  disjoint  sets  Hi,  02,  where  Hi  is  the  set  of  processes  that  are  sensitive  to  at  least  one 
input  port  (lienee,  TI2  =  H  \  Hi).  It  is  clearly  not  possible  to  determine  a  priori  whether  a 
process  P  €  Hi  is  invoked  in  the  simulation  (after  its  initial  invocation).  Thus,  there  is  some 
simulation  in  which  these  processes  are  invoked  infinitely  often,  and  the  SDG  must  include 
dependences  for  these  calls.  In  contrast,  any  non-initial  invocations  of  a  process  (^  €  02  must 
occur  after  an  assignment  to  a  signal  that  Q  is  sensitive  to,  and  such  invocations  are  handled 
using  the  signal  dependences  discussed  above.  Given  these  two  observations,  a  CFG  for  the 
master  process  comprising  the  following  (pseudocode)  steps  can  be  constructed: 


for  (5  G  O  -  initial  invocations  of  each  process 
call  Q 

while  (true)  -  subsequent  invocations  of  Oi  processes 
for  P  eUi 
call  P 


Given  PDGs  for  the  master  process  and  each  procedure  in  the  VHDL  program,  the  SDG  is 
constructed  as  usual. 

4.4  Correctness 

Our  motivation  for  the  VHDL  mapping  discussed  above  is  captured  in  the  following  theorem: 
First,  define  a  VHDL  process  invocation  trace  to  be  a  sequence  T  =  (Tj,  T2,...,  Ti, . . .),  where 
Ti  G  2^,  and  Ti  is  the  set  of  processes  that  are  invoked  on  simulation  cycle  i  of  the  trace. 

Theorem  1  Let  the  VHDL  program  H  have  a  process  invocation  trace  T  =  (Ti,T2, . . . ,  T, . . .), 
Then,  for  any  Pj  G  T,  either  Pj  E  Hi  or  there  is  a  signal  dependence  from  some  statement  in 
Pk  G  Ti  to  Pj  for  some  I  <  i. 

The  correctness  of  the  theorem  can  be  seen  to  follow  from  VHDL  operational  semantics. 

From  the  theorem,  we  can  conclude  that  the  VHDL  slicing  algorithm  is  correct,  since  any 
inter-process  dependences  will  have  corresponding  call  edges  in  the  SDG,  by  construction. 

5  The  Slicer 

As  mentioned  earlier,  the  VHDL  slicer  is  constructed  using  Codesurfer  [24],  a  toolset  developed 
and  marketed  by  Grammatech,  Inc.  The  toolset  consists  of  reusable,  multi-lingual  components 
for  building  and  operating  on  dependence-graph,  call  graph,  and  symbol-table  representations  of 
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\  / 


Scheme  Scripts 


Figure  6:  VHDL  Slicer  Architecture 


specifications  arid  programs.  The  dependence  graph  is  presented  as  an  abstract  data  type,  with 
interfaces  in  both  C  and  Scheme.  The  toolset  supports  efficient  implementations  of  powerful 
oj^erations  on  program  dependence  graphs,  such  as  precise  interprocedural  slicing  and  chopping. 

Figure  6  illustrates  the  architecture  of  the  VHDL  slicer.  The  CFG  Extractor  and  SDG 
Builder  perform  the  algorithm  described  in  Section  3  and  output  the  SDG  as  well  as  a  map 
from  PDG  nodes  to  source-text  references.  The  slicing  and  chopping  algorithms  are  embedded 
in  the  slicer  core. 

The  user  interface  for  a  program-slicing  tool  is  through  the  source  code:  By  maintaining 
apj)ropriate  maps  between  the  underlying  SDG  on  which  slicing  is  performed  and  the  source 
code,  the  user  specifies  the  slicing  criterion  by  selecting  program  elements  in  the  display  of 
the  source  code,  and  the  slice  itself  is  displayed  by  highlighting  the  appropriate  parts  of  the 
program.  Slices  may  be  forward  or  backward,  and  unions  of  slices  may  be  computed  using  the 
GIT.  The  toolset  GUI  also  supports  browsing  of  projects  and  project  files,  as  well  as  navigation 
through  dependence  graphs,  slices,  and  chops.  The  user  may  also  write  scripts  for  operating 
on  the  dependence  graphs  of  his  program;  scripts  are  written  in  STk  -  an  implementation  of 
Scheme  enhanced  with  the  Tk  graphical  user-interface  widgets.  Data  types  internal  to  the  slicer 
are  lifted  into  STk,  and  the  user  interface  is  built  up  around  them. 

5.1  Tool  Walkthrough 

To  give  a  feel  for  the  interface  and  some  capabilities  of  our  tool,  we  use  a  simple  VHDL 
program,  consisting  of  1  D  flip-flop  and  2  logic  functions  (Figures  7,  8)  L  The  project  view 
provides  hierarchical  summary  information  that  is  interactively  viewable  (partially  shown  in 
the  figure),  while  the  file  view  provides  the  actual  text  comprising  the  program. 

Figure  9  shows  a  file  view  of  the  executable  statements  in  the  forward  slice  on  the  program 
point  tl  <=  to  AND  not  (a)  ;.  As  expected,  the  slice  includes  the  flip-flop  but  not  any  input 
circuitry.  In  large  files,  the  colorbars  to  the  right  of  the  scrollbar  allow  the  user  to  quickly  scroll 

^The  screenshots  reproduced  here  are  dithered  monochrome  versions  of  the  color  tool  output,  and  thus  suffer 
from  some  loss  of  clarity  here 
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Figure  7:  Example  Project  Viewe 


;^e  ■ "  .‘.■•tttii;  V.-.  Qu'^es; ;  ’.  •iFuiictiphs: V •. -.Go. -VMiifdDVi/.;'. : 

ENTITY  clocking  IS 

PORT (a,  elk,  din:  IN  boolean; 
f ,  fb:  OUT  boolean) ; 

END  ENTITY  clocking; 

ARCHITECTURE  behavioral  OF  clocking  IS 
SIGNAL  to,  tl:  boolean; 

BEGIN 

to  <=  not (elk)  or  a; 

PROCESS  BEGIN 
WAIT  ON  to,  a; 
tl  <=  to  AND  not (a) ; 

END  PROCESS; 

PROCESS  BEGIN 
WAIT  ON  tl; 
f  <=  din  AFTER  5  nG; 
fb  <=  not (din)  AFTER  5  ne; 

END  PROCESS; 


Figure  8:  Example  File  Viewer  vi( 
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i  -Rie  :  .  Help  J 


ENTITY  clocking  IS 

PORT (a,  elk,  din:  IN  boolean? 
f,  fb;  OUT  boolean); 

END  ENTITY  clocking? 

ARCHITECTURE  behavioral  OF  clocking  IS 
SIGNAL  to,  tl:  boolean? 

BEGIN 

to  <=  not (elk)  or  a? 

PROCESS  BEGIN 
WAIT  ON  to,  a? 

END  PROCESS? 

PROCESS  BEGIN 

,diri  .5  ‘n,©/?* 

’5' •  ne 

END  PROCESS? 


Figure  9:  Forward  slice  on  tl  <=  tO  AND  not  (a)  ; 


to  the  slice. 

Figure  10  shows  a  project  view  of  the  backward  slice  on  the  same  program  point  as  above. 
This  time,  the  slice  excludes  the  flip-flop. 


6  Applications 

There  are  numerous  applications  of  slicing  in  hardware  simulation,  design,  testing,  and  formal 
verification,  and  we  describe  these  applications  in  this  section. 


6.1  Design 

Some  questions  that  a  sheer  can  help  answer  during  design  include: 

•  What  part  of  the  circuit  is  in  the  control  path  (not  datapath)? 

•  What  part  of  the  circuit  is  responsible  for  one  particular  circuit  function  (in  a  multi¬ 
function  circuit)? 

•  What  part  of  the  design  is  relevant  to  the  actual  function  (and  not  the  design-for-test 
and  debug  circuitry)? 

•  When  reusing  an  existing  IP  design,  how  should  it  be  modified  to  meet  the  new  chip 
requirements? 

Most  circuits  perform  multiple  functions,  and  it  is  desirable  to  be  identify  the  circuit  portions 
that  perform  a  function  of  interest,  so  that  the  designer’s  attention  is  focused  appropriately. 
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Figure  10:  Backward  slice  on  tl  <=  tO  AND  not  (a) ; 

Slicing  provides  a  mechanism  to  automatically  perform  this  isolation.  In  many  circuits,  non¬ 
functional  (e.g.  design-for-test  and  debug)  circuitry  often  dwarf  the  functional  circuitry,  and 
slicing  allows  the  high-level  architectural  designer  to  ignore  these  lower-level  circuit  details. 

Another  use  of  slicing  occurs  when  reusing  IP  Macros.  In  order  to  effectively  and  efficiently 
design  system  LSIs  (system-on-a-chip  LSIs),  it  is  desirable  to  reuse  existing  designs  as  much  as 
possible,  as  it  is  unrealistically  time-consuming  to  design  the  entire  LSI  chip  from  scratch.  An 
increasingly  popular  methodology  is  to  build  chips  from  existing  design  components  registered 
as  IP  macros.  However,  slight  modifications  to  the  IP  macros  are  needed  to  meet  the  new 
chips  requirements  (e.g.,  interface  with  other  chip  components,  additional  or  unneccessary 
functionality  in  the  reused  designs).  The  efficiency  of  these  modifications  is  a  key  issue  in  system 
LSI  design.  Modifiable  IP  macros  are  mostly  given  in  terms  of  VHDL/Verilog  synthesizable 
BTL  descriptions  (so  called  soft-macros),  and  users  must  understand  RTL  code  internals  in 
order  to  modify  IP  macros. 

There  are  several  levels  of  modification  that  are  made  to  IP  macros  when  they  are  reused, 
and  slicing  can  assist  these  as  follows: 

•  Changing  polarities  of  inputs  or  outputs  or  adding  encoders/decoders  to  inputs  or  out¬ 
puts  of  the  IP  macros:  Slicing  (using  the  appropriate  inputs/outputs  as  criteria)  assists 
designers  in  determining  where  to  make  these  modifications  efficiently. 

•  Deleting  functionality  from  an  IP  macro:  Slicing  can  be  directly  applied  to  extract 
reusable  code  portions.  For  example,  we  obtain  a  2-channel  ATM  from  a  4-channel 
ATM  by  slicing  with  respect  to  two  ATM  output  ports.  Similarly,  we  slice  an  MPEG  en¬ 
coder/decoder  with  respect  to  the  P  frame  outputs  to  obtain  a  simpler  encoder/decoder 
similar  to  a  motion  JPEG  encoder/decoder. 

•  Adding  new  functionality  to  an  IP  macro:  A  common  way  of  adding  new  functionality 
is  to  describe  it  in  a  new  VHDL/Verilog  module,  and  connect  it  with  the  existing  macro 
through  multiplexors.  However,  this  is  notoriously  inefficient  since  no  code  is  shared  even 
if  the  modules  are  similar.  Slicing  can  be  used  to  determine  macro  portions  related  to  the 
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new  functionality,  thus  minimizing  the  added  code.  If  the  difference  between  the  original 
code  and  the  new  code  is  small,  we  can  even  expect  similar  delay/areas  performance  from 
the  circuits.  This  predictability  is  very  important  in  hardware  designs. 

For  exam])Ie.  consider  high-speed  communication  chips.  As  network  data  rates  increase, 
communication  chip  macros  designed  earlier  for  slower  data  rates  can  be  reused  by 
adding/niodifying  functionality  associated  with  data/cell  processing  portions  of  the  com¬ 
munication  chip.  Slicing  can  be  used  to  identify  the  portions  of  the  VHDL/Verilog  code 
associated  with  the  data/cell  processing  functionality  and  reuse  those  portions. 

Moreo\’er.  if  appropriate  process  techniques  are  applied  in  logic  synthesis,  then  we  can  use 
VHDL  slicing  before  RTL  code  generation  and  still  modify  gate  level  circuits  for  the  original 
IP  macros  efficiently.  We  can  thus  modify  hard-macros,  i.e.,  macros  that  already  have  layout 
information  (placement  and  routing). 

6.2  Simulation 

Some  questions  that  a  sheer  can  help  answer  during  simulation  include: 

•  What  code  portions  can  potentially  cause  an  unexpected  signal  value  found  in  simulation? 

•  What  portions  of  the  circuit  can  be  affected  by  changing  a  particular  code  segment? 

•  What  potentially  harmful  interactions  with  other  modules  can  result  from  changing  a 
particular  code  segment? 

When  debugging  a  simulation,  designers  routinely  trace  backward  (in  time  and  program 
state)  from  a  point  where  a  signal  holds  an  unexpected  value.  If  the  slicing  criteria  is  the  set 
of  statements  that  potentially  assign  the  value  to  the  signal,  a  backward  slice  is  precisely  the 
subset  of  the  program  that  the  designer  must  trace  through,  and  the  remainder  of  the  program 
may  safely  be  ignored. 

If  a  code  module  is  updated,  a  forward  slice  on  the  updated  portion  identifies  the  portions  of 
the  circuit  that  can  potentially  be  affected  by  this  update.  Moreover,  if  that  slice  includes  code 
from  other  hardware  units,  the  designer  may  be  alerted  to  unexpected  potential  interactions 
that  may  result  in  the  introduction  of  new  bugs  due  to  the  update. 


6.3  Testing 

Testing  issues  which  a  sheer  can  provide  assistance  for  include: 

•  What  execution  paths  are  covered  by  a  given  test  vector? 

•  What  part  of  the  circuit  must  be  retested  if  a  certain  code  segment  is  changed  (i.e. 
regression  testing)? 

•  What  portion  of  a  circuit  is  controllable  from  a  given  set  of  input  ports? 

•  What  portion  of  a  circuit  is  observable  from  a  given  set  of  output  ports? 
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Figure  11:  Benefits  of  Slicing  for  Formal  Verification 


•  What  portion  of  a  circuit  is  testable  (i.e.  both  controllable  and  observable)  from  a  given 
set  of  input  and  output  ports? 

Test  plan  generation  is  a  complicated  and  time-consuming  task.  Part  of  this  task  involves 
the  identification  of  execution  paths  that  are  covered  by  a  given  test  vector.  Slicing  provides 
assistance  in  identifying  these  paths.  For  the  same  reason,  slicing  assists  in  determining  which 
test  vectors  need  to  be  rerun  if  a  certain  code  segment  is  changed. 

Another  major  research  area  in  testing  involves  the  use  of  metrics  to  quantify  how  testable  a 
circuit  is,  if  only  some  subset  of  inputs  and  outputs  is  available  during  test.  A  forward  slice  from 
the  input  subset  provides  an  upper  bound  on  circuit  controllability,  while  a  backward  slice  from 
the  output  subset  provides  an  upper  bound  on  circuit  observability.  Then,  the  intersection  of 
these  two  slices,  or  alternatively  the  program  chop  from  the  input  to  the  output  subset,  provides 
an  upper  bound  on  circuit  testability.  In  all  three  cases,  slicing  provides  a  metric  that  can  be 
used  when  constructing  test  plans. 

6.4  Formal  Verification 

HDL  slicing  is  particularly  useful  in  model  checking  to  prove  circuit  correctness.  The  major 
problem  in  model  checking  is  state  space  explosion.  Given  a  temporal  logic  specification,  let  the 
support  of  the  specification  be  the  set  of  variables/signals  in  it.  Then  a  backward  slice  on  the 
set  of  statements  assigning  values  to  these  variables  results  in  a  subset  of  the  program  consisting 
of  only  the  statements  that  can  potentially  affect  the  correctness  of  the  specification.  Figure  11 
illustrates  the  state  space  reduction  that  was  achieved  in  the  verification  of  the  controller  logic 
for  a  RISC  processor,  using  the  model  checker  described  in  [2]. 


7  Related  Work 

The  only  other  application  of  program  slicing  to  HDLs  that  we  are  aware  of  is  by  [25],  which 
discusses  a  number  of  issues  and  applications  related  to  VHDL  slicing.  However,  the  work 
presented  there  is  motivational  in  nature,  and  we  are  not  aware  of  any  resulting  automatable 
approaches.  To  the  best  of  our  knowledge,  we  are  the  first  to  have  implemented  a  tool  to 
automatically  slice  VHDL  programs. 

SDG-like  structures  form  the  basis  of  many  gate-level  test-generation  algorithms.  However, 
our  approach  works  at  the  VHDL  source  level,  thus  avoiding  the  heavy  complexity  of  synthesis. 
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Moreover,  many  applications  of  slicing  described  in  Section  6  make  sense  only  at  the  VHDL 
source  level. 

A  third  area  of  related  work  occurs  in  the  model  checking  domain,  where  state  space  size  is 
reduced  using  the  cone  of  influence  reduction  (COI)  or  localization  reduction  ([26]). 

COI  can  be  expressed  as  a  fixpoint  computation  that  constructs  the  set  of  state  variables  that 
can  potentially  affect  the  value  of  a  variable  in  the  CTL  specification  (i.e.,  the  set  of  variables 
in  the  cone  of  influence  of  the  variable  of  interest).  Alternatively,  COI  can  be  thought  of  as 
building  a  dependence  graph  for  the  program,  and  then  using  graph  reachability  to  determine 
what  parts  of  the  specification  are  relevant  to  the  variable  of  interest.  The  actual  dependence 
graph  may  be  either  on  the  VHDL  source-code  {pre- encoding)  or  on  the  set  of  equations  that 
represent  the  transition  function  [post-encoding). 

The  localization  reduction  performs  a  related  function.  Intuitively,  it  works  by  conserva¬ 
tively  abstracting  system  components  and  verifying  a  localized  version  of  the  specification.  If 
the  localized  version  is  not  verifiable,  the  abstractions  are  iteratively  relaxed  by  adding  more 
components,  until  the  specification  is  eventually  provable.  Added  components  are  in  the  spec¬ 
ification’s  COI. 

Several  differences  between  these  two  reductions  and  slicing  are  worth  noting  (the  first  3 
apply  only  if  the  reductions  are  done  as  post-encoding  operations): 

•  In  HDL  verification,  the  difficulty  often  lies  in  model  generation  rather  than  model  check¬ 
ing,  and  it  is  sometimes  not  even  possible  to  build  the  model.  Any  post-encoding  method 
obviously  does  not  help  in  such  cases. 

•  The  model  generation  process  often  does  some  translation  of  the  VHDL  program  into  a 
restricted  VHDL  subset,  and  it  is  thus  difficult  or  impossible  to  trace  back  to  statements  in 
the  original  program.  Most  of  the  design,  simulation,  and  testing  applications  mentioned 
in  this  report  are  consequently  not  possible  using  a  post-encoding  technique. 

•  One  of  the  variables  that  the  model  size  is  a  function  of  is  the  size  of  the  input  program 
(e.g.,  the  bits  needed  to  represent  the  program  counters).  Post-encoding  reductions  cannot 
reduce  this  overhead  in  general. 

•  Slicing  permits  more  complex  reductions  of  programs  to  be  specified  than  is  possible  using 
COI.  For  example,  suppose  the  specification  is  of  the  form  “Signal  x  is  always  false.  In 
verification,  we  are  primarily  interested  in  ensuring  that  counterexamples  in  the  original 
program  are  also  in  the  slice.  Thus,  we  can  select  the  set  of  all  statements  that  potentially 
assign  non-false  values  to  x  as  the  slicing  criterion,  and  perform  a  backward  slice  with 
respect  to  these  statements  to  produce  the  desired  reduced  program.  In  the  most  general 
case,  the  structure  of  the  specification  can  be  analyzed  to  determine  the  appropriate 
combination  of  forward  and  backward  slices  that  result  in  an  equivalent  program. 

In  some  cases,  slicing  also  has  a  disadvantage  compared  to  the  postencoding  versions  of  the 
other  reductions  mentioned  above,  since  it  is  applied  at  the  level  of  granularity  of  the  source 
rather  than  bits. 
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8  Conclusions 


In  this  report,  we  have  shown  how  to  extend  traditional  slicing  techniques  to  VHDL,  using 
an  appioach  based  on  capturing  the  operational  semantics  of  VHDL  in  traditional  constructs. 
We  have  implemented  a  tool  for  automatic  slicing,  and  the  report  listed  many  applications  of 
the  tool  along  with  some  experimental  results  showing  the  state  space  reduction  achievable  in 
model  checking.  We  are  currently  pursuing  further  research  along  four  lines.  First,  we  are 
enhancing  the  supported  VHDL  subset.  There  are  no  theoretical  limitations,  and  we  expect  to 
be  able  to  slice  almost  all  of  elaborated  VHDL  soon.  Second,  we  are  investigating  techniques  to 
achieve  more  precise  slices,  by  capturing  VHDL  semantics  more  accurately  in  the  SDGs.  The 
cuiient  SDGs  are  conservative  in  allowing  for  more  dependences  than  actually  exist,  and  more 
intei-cycle  analysis  of  VHDL  can  remove  some  of  these  dependences.  Third,  we  are  working  on 
developing  slicing  techniques  for  general  concurrent  languages,  since  the  techniques  described 
here  extend  readily  to  other  concurrent  languages.  Finally,  we  are  developing  a  theoretical 
basis  for  slicing  with  respect  to  CTL  specifications  for  use  in  formal  verification. 
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